CockroachDB: The Definitive Guide
We wrote the book on distributed scale. Literally.
Free O'Reilly BookTL;DR - Multi-region application architecture makes applications more resilient and improves end-user experiences by keeping latencies low for a distributed user base.
This blog will dive into each of the top five reasons why multi-region application architecture is worth building.
1. Fault tolerance in multi-region application architecture
Fault tolerance is the ability of a system to endure a failure of some kind and continue to operate properly.
The unfortunate reality is that failures happen. A fire, a flood, or an extreme storm can take out a data center, an availability zone, or an entire region. But that doesn’t have to result in an outage.
Multi-region applications are resilient in a way that single region and single availability zone applications are not. Single region architecture can survive machine failures. Single availability zone architecture can survive an AZ failure. But only a multi-region application architecture can survive a region failure.
If your application has high-availability requirements then multi-region architecture is important.
2. Low latency for geographically dispersed users
How do you get low latency when users are spread out? Multi-Region application architecture helps deliver low latency by making it possible to keep data close to users even when those users are distributed all over the world. Consider an example:
Imagine your business has users in New York City and Sydney, Australia. If you just deploy your application in a data center near New York, then users in Sydney will experience high latencies. They have to wait while their requests travel all the way to New York and back. But if you deploy your applications in multiple regions, and you put another data center closer to Sydney, then the client request time will dramatically improve.
A good rule of thumb is to keep latencies under 100 milliseconds. That is the maximum threshold for an experience to feel instantaneous. When a user base is spread out all over the world it’s challenging to keep latencies under 100 ms because the data is limited by the speed of light. The only way to achieve low latency, and great user experiences, is to keep the data close to the users with multi-region application architecture.
3. Grow a user base
Some organizations prefer to gain a meaningful quantity of users in a new region before adding a database in that region. There is a risk to this strategy. If your only data centers are in US-East then you’re most likely serving users in Sydney a high latency experience. If those users are having bad experiences then your application is unlikely to grow.
Other companies take the opposite approach. A good example would be the online sports gambling companies from Europe that chose to add data centers in the United States as soon as gambling became legal in some US states. These businesses saw the potential to gain new users and then scaled their application architecture to that new region to make sure the new users would have a good experience.
4. Application architecture flexibility
Once multi-region application architecture is in place, it becomes easier to scale applications up or down. There are three primary reasons why this is the case:
Database schema
When you design a schema for multi-region architecture, you need to partition your database, which requires identifying a column to partition on, actually partitioning the database on that column, and then setting up zone constraints. If you do that once, it’s a much lower lift to just add new regions with ALTER statements.
Cloud deployments
You have your database and your application deployed in multiple servers, across multiple regions. Most cloud providers make it easy to just add another regional server. Then you just need to deploy the database and app to that server. It’s also likely the case that you have used docker and a kubernetes engine to deploy the database and the app, which means you’ve written some docker and kubernetes deployment configuration files (i.e. a Dockerfile and a Kubernetes manifest file). With these already written, you simply use them to deploy to a new region. This is much easier than writing the files from scratch.
Application logic
You’ve already written the application to filter queries on partitions, and possibly to be aware of user locations. This means you don’t have to edit the application very much in an expansion to a new region.
To return to the example above, it would be much easier for the online sports betting company to expand into the US if they already had a multi-region deployment in Europe.
5. Comply with data privacy laws & regulations
There are now over 200 data privacy and data storage regulations around the world, the most famous probably being GDPR. And all the signs indicate that there will be more of these regulations every year. These regulations often prohibit storing certain data outside of certain boundaries. With the right multi-region deployment, you can keep data where it legally needs to be, by pinning data within the boundaries of a physical location.
Additional resources and next steps
If you’re building an application with the hope or the expectation that your user base will extend beyond a single region then it makes sense to research ways to build multi-region application architecture. Here are a few links to get you started:
